The Session Initiation Protocol (SIP) is defined in IETF RFC3261 (Rosenberg et al., June 2002). In general, the SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. The sessions can include Internet telephone calls, multimedia distribution and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols.
In addition, an IETF draft “draft-ietf-sip-content-indirect-mech-03”, entitled “A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages” (S. Olson, Jun. 2, 2003), describes the mechanism to provide for content indirection in SIP messages. More specifically, the purpose of the SIP is to create, modify, or terminate sessions with one or more participants, and SIP messages, like HTTP, are syntactically composed of a start line, one or more headers, and an optional body. Unlike HTTP, SIP is not designed as a general purpose transport of data.
There are various reasons why it may be desirable to indirectly specify the content of the SIP message body. For bandwidth limited applications, such as in cellular wireless applications, indirection provides a means to annotate the (indirect) content with meta-data which may be used by the recipient to determine whether or not to retrieve the content over the resource limited link. It is also possible that the content size to be transferred might potentially overwhelm intermediate signaling proxies, thereby unnecessarily increasing network latency. For time-sensitive SIP applications, this may be unacceptable. The use of indirect content can alleviate these shortcomings by moving the transfer of the content out of the SIP signaling network and into a potentially separate data transfer channel. There may also be scenarios where the session related data (body) that needs to be conveyed does not directly reside on the endpoint or User Agent (UA). In such scenarios, it is desirable to have a mechanism whereby the SIP message can contain an indirect reference to the desired content. The receiving party would then use this indirect reference to retrieve the content via a non-SIP transfer channel, such as HTTP, FTP, or LDAP. It is stated in this IETF draft that the purpose of content indirection is purely to provide an alternative transport mechanism for SIP Multipurpose Internet Mail Extensions (MIME) body parts. With the exception of the transport mechanism, indirected body parts are equivalent, and should have the same treatment, as in-line body parts.
In general, MIME is originally intended to extend the format of Internet mail to allow non-US-ASCII textual messages, non-textual messages, multipart message bodies and non-US-ASCII information in message headers. The following RFCs define MIME: RFC 2045: MIME Part One: Format of Internet Message Bodies; RFC 2046: MIME Part Two: Media Types; RFC 2047: MIME Part Three: Message Header Extensions for Non-ASCII Text; RFC 2048: MIME Part Four: Registration Procedures; and RFC 2049: MIME Part Five: Conformance Criteria and Examples.
Another IETF draft “draft-khartabil-sip-policy-uri-call-info-purpose-00”, entitled “Conveying a Session Policy Uniform Resource Identifier (URI) in the Session Initiation Protocol (SIP)” (H. Khartabil and A. Niemi, Feb. 5, 2004) describes an extension to a Call-Info header field for introducing a new purpose parameter value that can be used by a request originator or recipient to convey a URI where certain information to a session can be accessed. More specifically, this IETF draft provides a “policy-uri” which can be used by a conference server to indicate the URI of the conference policy to a UA participating in that conference.
The above-mentioned IETF draft document “draft-ietf-sip-content-indirect-mech-03” defines the SIP content indirection mechanism as providing an alternative transport mechanism for SIP MIME body parts. This is done by providing a URI for the indirect content, where the URI is specified in a “URI” parameter of the message/external-body MIME type.
However, before conveying this URI in a SIP request or response, the SIP client needs to be informed of the URI so that it can upload the indirect content before the indirect content is referenced in a SIP request or response. The IETF draft document draft-ietf-sip-content-indirect-mech-03 does not define the client or server behavior with respect to determining a URI to be used for content indirection. That is, what was not defined, prior to this invention, was a technique or protocol for a SIP UA to request, or be informed of, a storage location on an Application Server (AS) wherein the SIP UA can store the information that is to be referred to by a subsequent content indirection operation.